マイクロサービスプラットフォームを EKS から ECS に移行しました - 東京ガス内製開発チーム Tech Blog

https://cdn.image.st-hatena.com/image/scale/fa71d1a4c8688dfeb890018be85484e74a9fdf46/backend=imagemagick;version=1;width=1300/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Ft%2Ftnktg%2F20260517%2F20260517072827.jpg

マイクロサービス基盤のEKSからECSFargateへの移行による運用負荷削減

移行背景

マイクロサービスプラットフォームの本番運用開始後の運用体制の逼迫

Kubernetes特有のバージョンアップ作業負荷の増大

EKSの自由度と引き換えの設定コストおよび学習コストの高さ

運用メンバー2名体制によるリソース不足

課題

EKSのサポート期間に伴う定期バージョンアップ対応

EKSアドオン, Istio, ArgoCDなどのエコシステム更新負荷

Kubernetesの概念・リソースの多さによるキャッチアップコスト

将来規模に対して過剰構成となったインフラの維持コスト

移行判断

ECSFargateのシンプルさと学習コストの低さ

EKS固有機能への依存がないことの確認

将来要件におけるECSでの対応可能性の検討

プロダクト価値向上と事業貢献を優先した意思決定

プロジェクト体制

プラットフォームチーム 2名＋ソフトウェアエンジニアリングチーム 1名の3名体制

約4ヶ月で本番環境の移行を完了

マイクロサービス増加前の適切なタイミングでの移行

移行後構成

実行環境にFargateを採用

EventBridge, Step Functions, ECSによるバッチ処理構成

ecspressoによるデプロイ運用

マネージドサービス活用による運用負荷削減

成果

バージョンアップ作業の消失によるインフラ保守時間の大幅削減

少人数でも安定運用可能な運用体制の実現

コスト削減, IaC推進, プロダクト開発へのリソース再配分

現時点での最適解としてのECS選択